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Foreword 


Project Ubin: A Singapore story 


Project Ubin is a collaborative project by Singapore's financial services industry to explore the use of Distributed 
Ledger Technology (DLT) for the clearing and settlement of payments and securities. Launched in 2016 by the 


w 





In many ways, Project Ubin symbolises the spirit o 


onetary Authority of Singapore (MAS) and The Association of Banks in Singapore (ABS), the project is named 
fter Pulau Ubin, a remote island and rural oasis that is home to Singapore's last kampongs or villages. 


f collaboration among the stakeholders in our Fintech 
ecosystem. It has brought together Singapore Exchange (SGX) and other financial institutions, along with 
business leaders, academia, and technology partners, who have supported MAS and ABS in identifying and 
pursuing common interests in the real-world applications of DLT to benefit the industry and consumers. 





Following Project Ubin Phases 1 and 2, the goal here is to take the collaborative energy and innovation to the 








next level, by fostering a strong stewardship for th 








e potential of central bank-issued digital currencies (CBDC) and 





reimagining real-time gross settlement architectures and their interoperability with separate securities ledgers. 


Together with MAS, SGX is pioneering this new phase of Project Ubin to uti 
versus Payment (DvP) for the settlement of tokenised assets. Project Ubin 


interoperability and finality of DvP, s 


tarting with Singapore Government Se 


ise DLT to develop Delivery 
DvP seeks to achieve interledger 
curities (SGS) for central bank-issued 





cash-depository receipts (CDRs) on separate ledgers. To explore possible DvP models, our technology partners 


developed prototypes to connect di 





contributions of Anquan Capital, De 


The contracts that define the roles of par 


fferent DLT platforms: Quorum, Hyper 





oitte, and Nasdaq, our technology par 





edger Fabric, Ethereum, Anquan, and 


Chain, each with varying capabilities and features. At this point in time, we would also like to acknowledge the 





tners for Project Ubin DvP. 


ticipants in Project Ubin Phase 2 were extended for the buyer-side 


transfer of CBDC and seller-side transfer of tokenised assets, starting with SGS on a trade-by-trade basis. Post- 
trade processes were simplified and settlement cycles compressed, while DvP contracts were designed for the 





enhanced protection of investors. 


We hope that the successful completion of Project Ubin DvP will pave the way for wider adoption of DLT-based 
settlement of tokenised assets. While we faced many challenges along this journey, this is an opportunity to 
share our learnings to encourage further experimentation in Singapore's FinTech ecosystem and bring greater 


benefits to all. 


Sopnendu Mohanty 

Co-chair, Project Ubin DvP 

Chief Fintech Officer 

Monetary Authority of Singapore 


Tinku Gupta 


Co-chair, Project Ubin DvP 


Head of Technol 


ogy 


Singapore Exchange 
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Executive summary 


The DvP-on-DLT project is an extension of Project Ubin. This project seeks to achieve interledger connectivity and 
settlement finality for SGS with CDRs on separate DLTs. 





To examine possible DvP settlement models and interledger interoperability, prototypes of different DLTs with 
varied capabilities and features were developed. These prototypes allow the transfer of tokenised assets such as 
SGS and CDRs on a trade-by-trade basis. 





We observed that this setup provides the flexibility to compress settlement cycles and simplify post-trade 
settlement processes. The industry has taken actions to move from T+3 to T+2, shortening the settlement cycle 
and thereby reducing underlying risk exposures. DLT could potentially be an enabler for the industry to eventually 
compress the settlement cycle even further. 


In addition, smart contracts for DvP could enable the consistent and coherent implementation of rights and 
obligations that will increase investor confidence and reduce compliance costs in the market. 








The solution design of prototypes also enables a Recognised Market Operator (RMO) to maintain a central role to 
monitor and facilitate market functionalities. Given that investor security is of paramount importance, the solution 
possesses the following key design features: 








e Account controls with multiple signature conditions 





e Contract locks utilising secure secrets 

e Time boundaries established for asset recovery 

e Dispute resolution through arbitration 

This paper will explore how DvP settlement finality, interledger interoperability, and investor protection may be 


realised using specific solution designs. In addition, it will highlight some future considerations for DvP-on-DLT and 
its impact on capital markets. 


Later on, this paper will also take a look at the private and public blockchain platforms employed by the appointed 
technology partners - Anquan Capital, Deloitte, and Nasdaq - to create the prototypes used in this project. 
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Distributed Ledger Technology 
in capital markets 


Blockchains are essentially implementations of DLT. A DLT is a virtual network built on contracts that consistently 
and coherently defines the rights and obligations of its participants'. In doing so, it may replace the need for 

an authority to enforce rules, disseminate information, and make decisions. Instead, DLT participants - each 
represented by a computer (node) on the network - simultaneously share, update, verify, and reach consensus 
on transactions. 


In addition, data involved in these activities is protected by cryptography, and is therefore immutable?, lowering 
the threat of cybercrime. With round-the-clock uptime, the ability of a network to live across multiple locations 
(sites, countries, or institutions), and the shouldering of complex tasks by computer code, it is easy to see why 
DLT has many business applications. Indeed, the effects of DLT on capital markets could potentially be game- 
changing (see Figure 1). 











While DLT holds the promise of reducing some of inefficiencies embodied in the current market infrastructure, 
much rigorous testing remains to be done before DLT proves itselfto be the de facto solution. 





Figure 1: The impact of DLT on the capital markets value chain 











Pre-trade Trade Post-trade 

Activities 

Research analytics and Order execution and Clearing and settlement Custody and asset 
risk management matching servicing 





Current pain points in capital markets 





Information flow lag time Operational hours Counterparty risk, Costly and there is a need 
restricted to business opportunity and financing for manual processing and 
hours and batch costs reconciliation 
settlement? 





Benefits of DLT in capital markets 








Transparent and 24/7 access to markets Elimination of Elimination of the need 

automated verification of and trading counterparty risk and to safekeep assets with 

asset ownership reduced costs immutable transaction 
records 

Improved confidence in Alignment for cross- Speedier, seamless asset Reduced operational 

market analysis based on border settlement recovery enabled by smart costs using blockchain for 

immutable data history capabilities contracts automated reconciliation 





Distributed, not decentralised 
Although the “D” in DLT stands for Distributed, it should not be mistaken for a decentralised system. The 


fact is that every aspect of DLT - including contracts, standards, protocols, databases, and algorithms - 
are all centric implementations. While in some cases, blockchain allows for disintermediation, in others, it 
allows the efficient and effective process automation that creates new value for customers and businesses. 





1 An individual, organisation or group. 
2 Cannot be altered, manipulated, or tampered with. 


3. Transactions are consolidated for each business day and then cleared at one time. 
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What is DvP? 
Simply put, a DvP transaction is one where the cash payment for a purchased security occurs prior to, or upon, 


its delivery, much akin to two counterparties (traders) meeting at an agreed tim 


With the transfer of one asset conditioned to the transfer of the other, counterparties are protected from 


e to exchange the agreed assets. 


principal risk, that is, the risk of the seller of a security failing to receive payment despite fulfilling delivery, or the 


risk of the buyer o 


DvP advancements in global capital markets 
take a look at some case studies of global financial institutions applying technology (DLT and 
ularly in securities settlement: a process otherwise known as DvP*. 





1 
2. 


w 


The ST 


n this section, we 
non-DLT) to capita 


tis worth noting that DvP need no 
arrangements built 
fulfil their trade ob 
counter and paying for it only when 
n March 
research 


markets, partic 





a security failing 


into settlement 











DvP settlement can be success 


Oo 








ledger and cross-ledger situations. 
respect to i) current market structures and practices, ii) overarching regulatory fram 


trade settlement processes such as arbitration, and i 





n recent years, 
of the current Australian C 
future technologies. Its findings cited 
process between the client and clearing house®. 


the Austra 


n response, ASX proposed an implem 
DLT-based clearing system 
application of DLT in secur 
also drive down operational costs. Savings garnered could then be passed on 








this year, the European Cen 
project known as STELLAS. 
across two different ledgers using DLT. The 


The design and construct ofthe 
and counterparty risks. To ensure fair sett 
cash payment and delivery of 
achieve finality, the transfer of 


ian Securiti 


earing House Electronic S 


in 2018, 
ities settlement to not only enable efficient trade settlement and reconciliation, but 


fo 


iev 
uti 


fully ach 
DLT so 








securities. 


t be instantan 


tis placed in 


tral Bank (EC 





on 








assets m 











to receive delivery despite fulfilling payment. 





ii) potential to en 








TELLA report has showcased experimental results and conceptual analysis of 
n this report, we will explore the market feasibili 


hance investo 


entation roadmap to replace the current CHE 


eous, and may be achieved through time-sensitive 
mechanisms, where participants? are given a reasonable timeframe to 
igations. For instance, imagine walking into a fast food restaurant, ordering a meal over the 
front of you. That is DvP at work. 


B) and the Bank of Japan (BOJ) published a report on a joint 
t detailed their’ attempt to evaluate DvP settlement on a single ledger and 
lowing findings were derived: 


ed without any connection between the ledgers. 
has a direct bearing on the participants’ exposure to principal 
ement, asymmetric time boundaries were designed for the release 


ust be made irrevocable upon completion of the transaction. 
The mitigation of risk exposures during the DvP process is essential to safeguard investors' interests and 
ensure a fair and orderly market. 


DvP success across single 
ty of DvP-on-DLT with 

ework that governs post- 
r security and confidence. 


es Exchange (ASX) embarked on a review of the capabilities and readiness 
ubregister System (CHESS) to tackle challenges posed by 
two key issues: duplication of records, and an 





inefficient reconciliation 


SS settlement system with a 


with plans to go live by 2021°. This move by ASX will support the commercial 





to inv 


costs, which would in turn boost market participation and trading volume. 
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estors through lower trading 


As defined by MAS in “Rules and Market Practices of the Singapore Government Securities Market”, DvP requires that “unless 


otherwise mutually agreed 
security transacted”. 


Buyers or sellers of a securi 


Bank and Bank of Japan. 20 
Assisted by R3, IBM and DG 


Retrieved from “CHESS Rep 
documents/public-consulta 


Retrieved from “CHESS Rep 


Lab. 











y involved in a transaction. 


ASX. [https://www.asx.com.au/services/chess-replacement.htm] 


o between the buyer and seller, settlement shall be on the basis of payment against delivery ofthe 


Adapted from “Securities settlement systems: delivery-versus-payment in a distributed ledger environment”. European Central 
8. [https://www.ecb.europa.eu/pub/pdf/other/stella_project_report_march_2018.pdf] 


acement: New Scope and Implementation Plan”. ASX. September 2018. [https://www.asx.com.au/ 
ions/response-to-chess-replacement-consultation-feedback.pdf] 


acement: ASX is replacing CHESS with distributed ledger technology (DLT) developed by Digital Asset”. 
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Solely on the subject of DvP, it has been observed that there has been a growing preference for shorter 
settlement periods over long-held industry norms. This trend is largely fueled by concerns over the risks linked to 
lengthy, inefficient post-trade practices that were uncovered by the 2009 financial crisis. In fact, many regulators 


and stock exi 


changes have looked into their own settlement cycles over the last 10 years to reassess their risk 


exposures. The European Central Counterparty members (EuroCCP)", Hong Kong", Japan'’, Singapore", to name 
a few, have either initiated studies to examine or have completed the migration from T+3 to T+2. 


Furthermore, a 2014 study!" conducted by the U.S. Depository Trust & Clearing Corporation (DTCC) 
recommended the compression of trade settlement cycles for equities, municipal and corporate bonds, and unit 


investment t 





rusts, from T+3 to T+2. DTCC also explored the possibility of shortening the settlement cycle further 


to T+1 as a future consideration to enhance investor protection (by reducing counterparty and principal risks). In 


other words, T+2, challenging as it is to accomplish, is far from ideal. 


Regardless of their reasons for pursuing DLT implementations or speedier DvP - or a combination of both 

- the common sentiment among financial institutions is clear: system inefficiencies have a direct bearing on 
the amount of risks and costs one is subjected to. In the face of these inefficiencies, DLT has emerged as a 
technology with the potential to enable Singapore to transform into the leading global financial centre in Asia. 


O Retrieved 


1 Retrieved 


2 Retrieved 
minasama 


3 Retrieved 


Exchange 
settlemen 











4 Retrieved 
com/news 











from “T+2 settlement cycle announcement”. European Central Counterparty. 11 June 2014. [https://euroccp. 


com/2014/06/11/t2-settlement-cycle-announcement] 


from “HKEX to introduce T+2 finality on 25 July”. Hong Kong Exchanges and Clearing Limited. 7 July 2011. [http://www. 


hkex.com.hk/news/news-release/2011/110707news?sc_lang=en] 


from “Move to T+2 settlement in Japan”. Japan Securities Dealers Association. [http://www.jsda.or.jp/shiraberu/ 
/t2_en_cyukan_201603.pdf] 

from “SGX proposes to make securities settlement and clearing safer and aligned with global practices". Singapore 
Limited. 29 November 2017. [http://infopub.sgx.com/FileOpen/20171129_SGX_proposes_to_make_securities_ 
_and_clearing_safer.ashx?App=Announcement&FilelD=480254] 

from “New DTCC Paper Details Benefits of Move to T+2 Settlement Cycle in U.S.". DTCC. 30 April 2014. [http://www.dtcc. 
/2014/april/30/new-dtcc-details-benefits-of-move-to-t-2-settlement-cycle-in-us] 
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Project Ubin 


On 16 November 2016, MAS announced that it was partnering R3, a blockchain-inspired technology company and 
consortium of the world's largest financial institutions, to produce a proof-of-concept to test the efficacy of DLT in 
facilitating interbank payments. 


This endeavour, known as Project Ubin, revolved around the core idea of having a central bank digital currency 

- a tokenised form of the Singapore Dollar (SGD) - on ledger. The project was named Ubin, after the name of a 
Singapore island that supplied much of the granite that was used to pave the Singapore-Johor Causeway that 
provided the foundation for bilateral trade and relations. Likewise, Project Ubin brings together industry players in 
a collaborative effort to shape the future of business and peoples' lives through technological innovation. 








Will DLT enable Singapore's financial services industry to become safer and more efficient by reducing risks and 
costs at home and across borders? Can DLT provide Singapore's financial ecosystem with a global competitive 
advantage? What are the implications of a central bank digital currency with widespread participation? What 
opportunities does DLT hold for industry players, and how will roles change and evolve? These are just some 

of the questions that Project Ubin aims to address across six distinct phases carried out over a pre-defined 
timeframe (see Figure 2). 




















In the following section, we take a look at the previous phases of Project Ubin: Digitalising the SGD, and Domestic 
interbank transfer. 


Figure 2: Project Ubin’s six distinct phases 


,O © O © Q 


Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: Phase 6: 
Digitalising Domestic Delivery versus Payment versus Target Cross-border DvP 
the SGD interbank Payment on DLT Payment for operating and Payment 
transfer cross-border model versus Payment 

settlement 


Phase 1: Digitalising the SGD 
In this phase, MAS and R3 explored the use of a central bank digital currency - a tokenised version of the 
SGD - for interbank payments. 


Phase 2: Domestic interbank transfer 
In this phase, MAS and ABS explored DLT-enabled interbank transfers and examined specific RTGS 


functionalities, such as queue handling and payment gridlock resolution. 


Phase 3: Delivery versus Payment on DLT (DvP-on-DLT) 
this phase, MAS and SGX collaborated to realise domestic DvP settlement on two separate blockchain 
atforms, which is the focus of this report. 


se 4: Payment versus Payment for cross-border settlement 
is future phase, the objective is to assess the feasibility of cross-border DvP. 


se 5: Target operating model 
is future phase, the objective is to evaluate the impact of DLT on existing regulatory framework and 
et processes. 





Phase 6: Cross-border DvP and Payment versus Payment 
In this future phase, the objective is to apply the learnings garnered to execute cross-border settlement of 
both payments and securities. 
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Project Ubin Phase 1: Digitalising the SGD 
Phase 1 of Project Ubin! was conducted over six weeks from 14 November 2016 to 23 December 2016, and 
served to assess the technical feasibility of using a tokenised form of the SGD issued by the central bank! for 


then create the equivalent value in 





transfers (payments) to each other 





inter-bank payments and settlement on a distributed ledger. 


n this system, participant banks pledge cash into a custody account held at the central bank, MAS. MAS will 


Digital SGD” on the distributed ledger'®, and assign them to the respective 


banks. Once the banks have received their Digital SGD transfers from the central bank, they are then free to make 








or the central bank. 


Phase 1 concluded successfully. Interbank payments can be made possible by the integration and synchronisation 


of the distributed ledger with MEPS+, MAS' Real-Time Gross Settlement (RTGS) system’. This implies that beyond 
enabling round-the-clock uptime and the traceability of records, distributed ledgers also possess the ability to 


preserve the integrity of the data h 
money market, where banks can le 








eld by existing electronic payments and book-entry systems. A Digital SGD 
nd to and borrow Digital SGD from one another without pledging cash with the 





central bank, is also no longer a distant possibility. 


Project Ubin Phase 2: Domestic 


interbank transfer 


Having proven that a Digital SGD could work on a distributed ledger for domestic inter-bank payments, the next 
logical step was to remove a hurdle common in the settlement process: payment gridlocks. Initiated by MAS and 


ABS, Phase 27° explored the use of 
Savings Mechanisms (LSMS)?!. 


DLT for specific RTGS functionalities, with a focus on distributing Liquidity 


Then, there was also the need to address the privacy of transactions. Three prototypes were developed on three 
distinct DLT platforms: Corda, Hyperledger Fabric, and Quorum. The goal was to operationalise a fully functional 
DLT-based RTGS system by the end of 13 weeks. 


[http://www.mas.gov.sg/~/media/Proj 


6 MAS is Singapore's central bank and 


8 The distributed ledger network, an E 
systems and RTGS systems, allows fo 





5 More information on Project Ubin Phase 1 can be found in “Project Ubin: SGD on Distributed Ledger”. Deloitte and MAS. 2017. 


ectUbin/Project%20Ubin%20%20SGD%200n%20Distributed%20Ledger.pdf] 


financial regulatory authority. MAS acts as a settlement agent, operator, and overseer of 
payment, clearing, and settlement systems in Singapore that focuses on safety and efficiency. 


7 These are in the form of depository receipts (coupons) that are exchangeable for SGD in cash. 


hereum-based blockchain which was designed to be compatible with current account 
ra working integrated transfer prototype. 





9 Afunds transfer system used by ban 


s to send payments to one another on a gross settlement basis. 


20 More information on Project Ubin Phase 2 can be found in “Project Ubin Phase 2: Re-imagining Interbank Real-Time Gross 


Settlement System Using Distributed 
ProjectUbin/Project%20Ubin%20Pha 


21 This refers to transactions that are se 


Ledger Technologies”. MAS and ABS. November 2017. [http://www.mas.gov.sg/~/media/ 
se%202%20Reimagining%20RTGS.pdf] 


ttled on a net basis. 
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RTGS systems 

RTGS systems are funds transfer systems that process a large number of high-value transactions requiring 
immediate settlement. There is therefore a demand on such systems to neutralise intraday liquidity gridlocks, 

by means of an LSM, to move transactions along. LSMs are traditionally found on centralised systems, as is the 
case for most RTGS systems around the world, where the algorithms necessary for their implementation usually 
require a consolidated, system-wide view of all payment instructions. This sharply contrasts with the concept of a 
distributed LSM offered by DLT. Singapore's equivalent of an RTGS system is the MAS Electronic Payment System 
(MEPS+)*2, operated by MAS. 


Payment gridlocks 
Atypical payment gridlock is a paradoxical scenario where senders and receivers are unable to settle queued 

payment instructions one-to-one, in a sequential manner, due to insufficient funds, despite the fact that the net 
liquidity held by all participants in the gridlock is sufficient for the simultaneous settlement of all transactions. 

If there are LSMs (private or public queue mechanisms) that can prioritise all payment instructions to trigger 
gridlock resolution - that is, enable incoming and outgoing amounts to coincide without any risk of a deficit - 
smoother settlements can be achieved and costly deadlocks” avoided. 











The idea of a DLT-based RTGS system with an efficient LSM is especially relevant in the context of capital markets, 
particularly with securities trading. While digitisation has shortened trading timeframes considerably, the same 
cannot be said for clearing and settlement, which can stretch up to three days (T+3). This delay is partly due 

to existing market structure and rules that dictate that both participants be given some time to secure the 
underlying assets during post-trade settlement. 








Figure 3: Impact on value chain 





Research Order entry Clearing and Transfer Trustee 
analytics and execution settlement agency services 
Risk Custody and s f Investor 
management asset servicing Financing services 

DvP cash 4 Account 





administration 


With distributed ledgers able to not only ascertain a buyer's liquidity, but also effect settlement within the trading 
phase itself, the time and monetary costs associated with post-trade financing may soon be a thing of the past 
(see Figure 3). This explains why a fully functional DLT-based RTGS system holds immense interest for industry 
players. Furthermore, DLT supports the use of smart contracts to automate or replace convoluted processes 
currently performed by clearing houses, back office systems, and registries. 


Phase 2 concluded with all three prototypes confirming that an RTGS system, complete with an LSM, could be built 
on a distributed infrastructure. This has significant implications considering that DLT is capable of 24/7 uptime 
and, therefore, the restrictions of market operating hours will no longer apply. The possibility of cloud deployment 
and use of bespoke functionalities to handle tokenised assets further supports the case for DLT adoption. 





22 MEPS+ plays an integral role in the functioning of Singapore's financial market. It processes about 25,000 transactions a day, with a 
total daily transaction value of up to SGD 70 billion. 


23 A deadlock arises when a gridlock results in a negative net liquidity across participants and becomes impossible to resolve without 
the injection of additional liquidity into the system. 
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Project Ubin: Delivery versus Payment on DLT 

On 24 August 2018, MAS and SGX announced their plan to realise DvP settlement of two tokenised assets across 
different blockchain platforms (distributed ledgers). The two tokenised assets are MAS-issued SGS and an MAS- 
issued central bank digital currency in the form of Digital SGD. 


Current MEPS+ DvP system 

EPS+ is an RTGS system implemented and operated by MAS, comprising two subsystems: MEPS+-SGS, and 
EPS+-IFT24, The former handles the scripless?5 settlement of MAS-issued SGS on a DvP basis, while the latter 
enables high-value SGD-denominated interbank funds transfers. Market participants must be registered with a 
central bank and an RMO, in this case, MAS, before they can engage in transactions (see Figure 4). The MAS SGS 
arket Committee” also has provenance over dispute resolution as an arbitrator. 





Figure 4: MEPS+ operated by MAS 
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Bank C's SGS accoun Bank C's RTGS account 


SGS Committee with provenance of both SGS 
and RTGS accounts 








Challenges and opportunities 

Systemic operational risks 

In a conventional settlement system, all participating banks that require settlement services will have to be 
connected to central operators (clearing houses and central banks) in order to settle their transactions. A central 
operator represents a single point of failure in this closed loop system (systemic risk). 


If DLT is a way to achieve connectivity between asset ledgers built on separate systems, we can effectively 
remove the systemic risk of siloed infrastructures, such as MEPS+. Distributing control to participants would in 
fact strengthen security resilience in the system since DLT makes the simultaneous hacking of multiple nodes 
extremely difficult. 





Although transactional mechanisms could be replaced by DLT, the role of a central operator remains a question 
to be answered. Would there be a need for legal oversight over transactions and the role of the arbitrator? 


24 MEPS+ interbank fund transfer system. 

25 Securities trading with no physical certificate issued or exchanged, and only represented as book entries. 

26 Section 3.4.3 on Amendment or Cancellation in SGS Rules & Market Practices mandates the recovery through arbitration by the 
SGS Market Committee. 


13 


Delivery versus Payment on Distributed Ledger Technologies | Project Ubin 


Operating hours 

The MEPS+ operates with fixed operating hours, and faces the same limitations imposed by fixed operating hours that 
plagues most, if not all, RTGS systems around the world. Going by current standards, it is simply unrealistic to expect 
round the clock trade-by-trade settlement. While clearing and settlement cycles characterised by T+2 or T+3 have 
become the industry norm, any delay in the settlement process fundamentally exposes trade participants to principal 
risks, 


With DLT enabling 24/7 uptime and continuous trade-by-trade settlement facilitated by LSMs, clearing cycles of T+3 or 
T+2 can be compressed and their associated risks, reduced. 


Compliance 
Adherence to contractual obligations is difficult for the central operator (clearing house) to enforce in practice. Often, 
extra processes, labour, and financial resources have to be committed to ensure compliance. Additionally, the current 
market setup does not completely mandate provenance on the securities. For example, it typically takes a number of 
years for a regulator to complete an overhaul in the financial services industry, particularly with regulatory changes, 
changes in compliance standards, and system upgrades. 


A DLT system can make use of smart contracts to contractually bind participants to operate in compliance. Although 
the benefits of such functionalities are appealing, we have to be prudent given the high-risk nature of the financial 
services industry. Would having a hybrid system combining a distributed network and a central operator work in 
practice? Does it include certain operational requirements to ensure that the framework is sufficiently robust to 
facilitate dispute resolutions? 

















Project objectives 

While the proposed implementation of DLT in the current settlement system could very well address the inherent 
drawbacks of present RTGS systems, the real test lies in proving its efficacy. To do this, we need to design and create 
DvP-on-DLT prototypes that can accomplish the following: 


e Interledger interoperability between cash and securities ledgers built on separate DLT platforms; 

e Mitigation of counterparty risks in DvP by enabling recovery on cash and securities ledgers; 

e Achievement of DvP settlement finality” with clearing members by counterparties; 

e Strengthening of investor confidence and an enhanced user experience in DvP with safe and sound recovery. 


In the next chapter, we will be exploring the feasibility of a DLT model that encapsulates these functionality 
requirements and the different approaches taken by our technology partners. 








27 When transaction obligations are fulfilled through the transfer of an asset or financial instrument to another party, and the 
underlying contract is discharged, deeming the transaction irrevocable. 
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DvP settlement design on DLT 


In this section, we 
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examine the achievement of DvP settlement in an environment where cash and securities are 


implemented on two different blockchains. We will also highlight the specifics of our solution: participants and 
their roles (see Figure 5), prototype features, and a baseline settlement process flow, with examples of success 


and failure cases. 


Platforms 
Our technology pa 
Quorum (Anquan), 


rtners created the prototypes on three DLT platforms: Anquan permissioned blockchain and 
Hyperledger Fabric and Ethereum (Deloitte), and Chain and Hyperledger Fabric (Nasdaq). The 


process flow described below is a generic one adopted by all three technology partners with slight deviations in 
design, including instances where transaction failures might occur, and where auto-recovery and arbitration are 


triggered. 


Figure 5: High-level overview of solution architecture 


r----------------------------- RMO platform cum arbitrator ----------------------- ` 


Prototype 1 


Prototype 2 


Prototype 3 


Key participants 
e RMO”: This enti 





E 
Securities 























Anquan 
Quorum Anquan Permissioned Blockchain 
Ethereum Deloitte Hyperledger Fabric 
Hyperledger Fabric Nasdaq Chain Inc. 











and ledgers 


ty has oversight of both ledgers and dealer activities. It could also assume the role of an 


arbitrator that has access to two key-pairs, with a pair on each ledger: one public, and one private in escrow. 


e Buyer: This enti 
two key-pairs, wi 


ty is an exchange-registered trader with accounts on both the cash and securities ledger, and 
th a pair on each ledger: one public, and one private. 


e Seller: This entity is an exchange-registered trader with accounts on both the cash and securities ledger, and 


two key-pairs, wi 


th a pair on each ledger: one public, and one private. 





e Cash ledger: Th 


is entity is the central bank-managed ledger for the tokenised Digital SGD asset. 


e Securities ledger: This entity is an exchange-managed ledger for the tokenised SGS asset. 


With their potential to reduce inefficiencies and costs, blockchains may well become a cornerstone of future 
financial ecosystems. Yet, there is also the potential flip side to consider: a fragmented global financial landscape 
borne on various blockchain protocols. Establishing connectivity between disparate blockchains is a daunting 


task, as each will h 
of profound intere 


28 For more informa 


ave its own unique set of rules and protocols. Hence, achieving interledger interoperability is 
st for the financial industry as a whole. 








tion, please refer to "Review of the Recognised Market Operators Regime". Monetary Authority of Singapore. May 


2018. [http://www.mas.gov.sg/~/media/MAS/News%20and%20Publications/Consultation%20Papers/2018%20May%2022%20 


RMO%203P/Cons 


ultation%20Paper%200n%20RMO%20Regime.pdf] 


15 


Delivery versus Payment on Distributed Ledger Technologies | Project Ubin 


Prototype features 

To achieve a DvP-on-DLT prototype that is fit for purpose, there needs 
challenges and current market structures. The proposed system must 
fulfilment of obligations, (ii) mitigate, among others, principal and coun 
state of settlement finality, and (iv) improve investor confidence. 


"u 
f 


For clarity, the terms “buyer”, “seller” and “counterparties” will be used 
Time boundaries 

For a DvP to successfully conclude, trade participants must perform th 
windows. The seller specifies a time window before the settlement pro 


in 


to be a thorough study of real-world 
be able to (i) aid trade participants in their 
terparty risks, (iii) allow for the conclusive 


place of “trade participants". 


eir obligations within specified time 
cess İs initiated where two distinct legs of 





he transaction will take place on the cash and securities ledgers. We h 
to ensure a fair settlement that prevents unnecessary risk exposure fo 


ave adopted asymmetric time boundaries 
r the participants. Our prototype also 


highlights the possibility of having a pricing mechanism to control the time validity of a transaction. For example, 
if a participant requires more time to acquire capital through financing, it could stipulate a longer settlement 
imeframe, subject to the agreement of the seller. 








Contract locks 
Contract locks render the amount of cash and securities committed by both buyer and seller untouchable on 
the respective ledgers. This prevents said assets from being used in another trade, hence removing the risk of 
payment and delivery defaults. The contract locks are in effect when counterparties commit to a transaction 
by sending instructions to the respective ledgers. The underlying assets will be locked and participants will be 
unable to use them in other transactions until the contracts are discharged when (i) the buyer and seller has 
fulfilled their obligations by transferring the asset to another party, or (ii) the contract has expired due to the 
imposed time boundaries. 





Account controls 
Counterparties are expected to fulfil two-of-three multi-signature conditions”? at various points of the 
settlement process to advance towards settlement finality. In this setup: 


e Buyer and seller will both hold individual private keys*°. 


e Arbitrator will be provided with an escrow private key for safekeeping. 


Participants engaged in a trade are subjected to this condition, where two of the three abovementioned 
authorised signatories must endorse the transaction in order for it to proceed to the next step. This also enables 
the arbitrator to be able to resolve disputes on the condition that either participant provides the first signature. 





Self-enforcing smart contracts?! 

While autonomous self-executing smart contracts offer convenience by automating processes and transactions, 
they could potentially work against the blockchain they serve. The workaround is to use smart contracts that are 
self-enforcing instead. With the RMO also assuming the role of an arbitrator, buyers and sellers are rendered a 
greater degree of protection. 


29 
30 
31 


A requirement that the transaction has to be endorsed by additional users before it can be propagated in a blockchain network. 
A private key allows a user to access their blockchain wallet and endorse (sign) a transaction to enable a transfer. 


Smart contracts are virtual agreements encoded on the blockchain network that are executed automatically based on logic 
conditions when the terms of the agreement are met. 


Secure secrets 


Our prototype mandate 


until finality is reached. 








to identify the recipient 











blockchain (see Figure 2 


Process flow of DvP-o 
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s the creation of a secret and its unique hash password as a means to ensure DvP 


nality: both buyer and seller have to use the same secret to effect asset transfer. Ideally, this secret should be 
generated by the RMO. The secret is sent to the seller in the form of an encrypted and password-protected PDF 
file at the start of post-trade settlement, and is used for the verification of instructions issued by counterparties 


The PDF file would also enclose the digital signatures of the signatories, which will allow participants to review 
the recipient of the transaction using on their public key” or encrypted address”, providing a security feature 


before initiating the transaction. This secure PDF is sent off-chain*4 and out-of-band, 





enhancing security for the market participants as the secret or its hash does not need to be stored on the 


2 in Appendix). 


n-DLT 


In our process flow example, the following takes place: both seller and buyer of securities agree to the “asset 
type”, “asset amount”, “locking time” and hash password (HashPwd) to be exchanged. The agreement comprises 
two sets of asset transfers: (i) securities from seller to buyer within 48 hours, and (ii) cash from buyer to seller 
within 24 hours. Both seller and buyer have access to the distributed ledgers where securities and cash are 


settled respectively and 


the flow of time of these networks is predictable to both counterparties. 


We examine four scenarios where DvP is carried out in a DLT-enabled environment: 
e Scenario 1: Settlement success 


e Scenario 2: Settlemen 
e Scenario 3: Failed tran 
e Scenario 4: Failed tran 








t failure with automatic recovery 
saction requiring arbitration 
saction with the introduction of an arbitrator 


32. Alarge integer number that is analogous to an “account” or “address” in which the sender will transfer the underlying asset to. 


33 Certain solution designs may choose to anonymise the public key through additional layers of encryption or central registry. 


34 Arecording and validation method that works outside the realm of blockchain technology, such as email or WhatsApp notifications. 
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Scenario 1: Settlement success 
In this scenario, settlement is successful as both buyer and seller fulfil their trade obligations in the following 
steps (see Figure 6): 





1. Matching engine or OTC platform 

Buyers and sellers submit orders to the matching engine or OTC platform. The matching engine or OTC 
platform matches the buyer's bidding price for a security with the seller's asking price. It then notifies these two 
counterparties that it will initiate post-trade settlement based on the exchange of the agreed asset type and 
amount, along with the payment amount. 


2. Secret and hash password generation 

The matching engine or OTC platform operated by the RMO generates a secret (a) and a hash password (HashPwd 
= H(a)) and shares them with the seller via an encrypted and password-protected file. Both will be used to verify the 
instructions subsequently exchanged between the two counterparties in the settlement process. 


3. First Securities Instruction (seller) 
Referencing the hash password, the seller creates the First Securities Instruction related to the transfer (delivery) of 
securities. In this instruction, the seller confirms the amount of assets to be exchanged for the agreed payment, and 
sets down the conditions for two possible end states. 


The first end state (Tx1) sees the buyer granted the right to claim the seller's securities if (i) the buyer supplies the 
secret that matches the hash password (contract-lock condition), or (ii) both buyer and seller endorse this end state, 
or (ili) either the buyer or seller, together with the securities arbitrator, endorses this end state. 





he second end state (Tx2) sees the seller granted the right to have his securities returned if (i) the buyer fails to 
supply the secret that matches the hash password within 48 hours (timeout condition), or (ii) both buyer and seller 
endorse this end state, or (iii) either the buyer or seller, along with the securities arbitrator, endorses this end state. 


he seller then endorses the First Securities Instruction (electronic signature) and submits it to the securities ledger. 














4. Consensus (securities ledger) 
The consensus mechanism of the securities ledger verifies and confirms the First Securities Instruction. It then 
updates the ledger with the result. At the same time, a securities contract lock - a smart contract referencing the 
hash password - locks up the amount of securities required by the seller for the trade. With the securities set aside 
on the ledger, a default on delivery is prevented. 











5. First Cash Instruction (buyer) 
After verifying the content of the First Securities Instruction submitted by the seller, the buyer creates the First Cash 
Instruction relating to the transfer (payment) of cash. In this instruction, the buyer sets down the conditions for two 
possible end states. 








The first end state (Tx3) sees the seller granted the right to claim the buyer's cash if (i) the seller supplies the secret 
that matches the hash password (contract-lock condition), or (ii) both seller and buyer endorse this end state, or (iii) 
either the seller or buyer, along with the securities arbitrator, endorses this end state. 


The second end state (Tx4) sees the buyer granted the right to have his cash returned if (i) the seller fails to supply 
the secret that matches the Hash Password within 24 hours (timeout condition), or (ii) both seller and buyer endorse 
this end state, or (iii) either the seller or buyer, along with the arbitrator, endorses this end state. The buyer then 
endorses the First Cash Instruction (electronic signature) and submits it to the cash ledger. 








6. Consensus (cash ledger) 

The consensus mechanism of the cash ledger verifies and confirms the First Cash Instruction. It then updates the 
ledger with the result. At the same time, a cash contract lock - a smart contract referencing the hash password - 
locks up the amount of cash required by the buyer for the trade. With the cash set aside on the ledger, a default on 
payment is prevented. 








35 Over-the-counter transactions carried out between two known trading parties. 
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7.Second Cash Instruction 

After verifying the contents of the buyer's First Cash Instruction, the seller creates the Second Cash Instruction 
(claiming the agreed amount of cash) that reveals the secret. The seller then endorses this instruction (electronic 
signature) and submits it to the cash ledger. 


8. Payment complete 
The consensus mechanism of the cash ledger verifies and confirms the Second Cash Instruction. It then updates 
the ledger with the result. At this point, the cash contract is discharged, and the seller receives the agreed 

amount of cash from the buyer. Payment is now complete. 


9. Second Securities Instruction 
Having received the secret supplied in the Second Cash Instruction of the seller, the buyer creates the Second 
Securities Instruction (claiming the agreed amount of securities) and inputs the secret. The buyer then endorses 
this instruction (electronic signature) and submits it to the securities ledger. 





10. Delivery complete 

The consensus mechanism of the securities ledger verifies and confirms the Second Securities Instruction and 
the secret. It then updates the ledger with the result. At this point, the securities contract is discharged, with the 
buyer receiving the agreed amount of securities from the seller. Delivery is now complete. 


Scenario 2: Settlement failure with auto recovery 
Regardless of how technically faultless a trading platform may be, it is still susceptible to human error: 
settlement failure could occur if any of the steps previously described in Scenario 1 are not followed 

through. 





For example, settlement could fail if the seller does not send the Second Cash Instruction within the time bound 
of 24 hours, implying that it would be unable to obtain payment. Having received no instruction to verify and 

confirm, the buyer is unable to proceed with the Second Securities Instruction. Yet, both seller and buyer suffer 
no risk of losing their assets because the assets has not changed hands. 





Through the use of smart contracts, the solution design enables automatic recovery (see Figure 7). The buyer, 
upon meeting the timeout condition of end state Tx4, is free to submit a cash instruction that will unlock and 
return his cash to the ledger after 24 hours. Similarly, the seller, upon meeting the timeout condition of end 
state Tx2, is free to submit a securities instruction that will unlock and return his securities to the ledger after 48 











hours. 


Scenario 3: Settlement failure requiring arbitration 

In this scenario, settlement could fail if the buyer fails to submit the Second Securities Instruction within 
the time bound of 48 hours. This implies that the buyer would be unable to obtain the securities even 
after the payment is delivered, thereby exposing himself to principal and liquidity risk. 





On the other hand, the seller has discharged the cash contract and claimed the payment (end state Tx3). 
However, the securities contract is still valid for the recovery of the committed securities (end state Tx2) - 
resulting in a lop-sided scenario where the seller now has received the cash payment, but continues to be in 
possession of the committed securities. This results in a possible dispute between the counterparties, and 
arbitration is now required (see Figure 8). 





Scenario 4: Settlement failure with introduction of an arbitrator 

In this scenario, settlement fails but an arbitrator is introduced to the settlement process (see Figure 9). 
Here, the buyer is able to call in an arbitrator (the trading platform) to help (i) recover the agreed amount 
of securities from the seller, or (ii) recover the cash that has already been paid. 








To achieve (i), the arbitrator, together with the buyer or seller, must endorse end state Tx1 (First Securities 
Instruction), to trigger the release and transfer of securities from seller to buyer. Alternatively, if (ii) is preferred, 
the arbitrator, together with the buyer or seller, must endorse end state Tx4 (Second Cash Instruction) to trigger 
the rightful return of cash from seller to buyer. 
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Figure 6: Process flow for settlement success 
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Figure 7: Process flow for settlement failure with auto recovery 
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Figure 8: Process flow for settlement failure requiring arbitration 
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Figure 9: Process flow for settlement failure with introduction of an arbitrator 
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Investor protection 

Assurance against account compromise 

Two-of-three multi-signature conditions function as useful account controls. 
na trade involving three participants (buyer, seller, and trading platform), 
no single participant can remove or steal the assets involved without the 
nowledge and endorsement of another. Hence, an arbitrator may resolve 
disputes by intercepting the transaction using an escrow private key?°. 


For example, if the seller loses the device that is used to access the email 
account to which the secret is sent, the assets cannot be stolen or removed 
by anyone in possession of the device (and secret) without knowledge of 

the private keys held by the seller, buyer, and platform. Likewise, even if a 
non-trading member knows the individual private key of the seller, buyer, or 
trading platform, it cannot claim the assets involved without knowledge of the 
other participants’ private keys and the secret. 


n addition to such conditional account controls, off-chain?” and out-of-band?8 
contract locks safeguard secrets using encrypted and password-protected 
files as defined by ISO 32000?°. The prototypes in the examples were 
designed to bear an electronic signature with document locks to protect it 
from tamper, thereby strengthening investor confidence and enhancing the 
experience. 





Arbitrator presence 

With the growing prominence of blockchain technology, account and 
transaction security issues have risen to the forefront. Convenient as it 
may seem to blame rogue dealers for exploiting technology for unlawful 
gains, such losses often stem from the lack of due diligence in conducting 
background checks, a healthy scepticism and, most glaringly, an avenue 
for recourse should things go wrong. Then there are also erroneous trades 
caused by mistakes such as the fat-finger error’®, which may result in 
extensive rollback issues for the financial intermediary (stock exchange). 











The examples included in this report promote the introduction of an 
arbitrator presence to ensure transaction integrity and protection of market 
participants. Indeed, having a regulatory authority in place to oversee 

the follow-through of transactions, remind dealers of their obligations to 
facilitate the meeting of deadlines, and amicably resolve disputes should they 
arise - including instances of errant trading - serves to not only to assure 
participants, but also imbue confidence. 
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A key held by a trusted third party that works in the same way as the disconnected and isolated back-up key stored in tamper- 
resistant smartcard chips, or key components in sealed envelopes used by segregated key-custodians. 


This refers to a recording and validation method that works outside the realm of blockchain technology. 


This refers to an authentication method used to confirm a user's rightful access to information. The authentication mechanism 
requires the user to provide two or more pieces of evidence: (i) something the user knows, (ii) Something the user has, or (iii) 
something the user is. In our DvP settlement scenario, the user (buyer/seller) must possess an on-chain private key (something the 
user has) and the secret/PDF file relayed via an off-chain communication channel (something the user knows). 


ISO standard of the PDF format. 


A fat-finger error is a human-keyboard input error, whereby a trading order of a far greater volume than intended, or for the wrong 
financial instrument, or at the wrong price, is placed. 
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Conventional arbitration 
Although it is true that arbitration can provide respite and closure for errors, we must be clear about what the 
process entails, and the possible implications of DLT on current practices. Some considerations include: 


Deadlines 

The SGX error trade rulebook states that “the matter must be referred to SGX-ST within sixty (60) minutes from 
the time the error trade occurred or before 18:00 hours on that trading day, whichever is earlier“. The arbitrator 
has the right to exercise discretion over whether to entertain reports made after the stipulated timeframe. 

With DLT, automated reminders encoded as smart contracts may be sent to counterparties to aid them in 
safeguarding their interests. 


Asset classes 

Different asset classes are governed by different rules. In particular, “SGX-ST will not review an error trade 
referred to it by a trading member, where the error trade falls at or within the upper and lower limits of 

a no-cancellation range, which is applied to the following instruments: (i) structured warrants, and (ii) all 
other securities and futures contracts, excluding bonds”. Here, smart contracts can again be employed to 
automatically determine if the conditions have been met, and smoothen the arbitration process. 


Costs 
SGX's rulebook states that “the requesting trading member must pay a trade review fee of $1,000 for each 
referral accepted for review by SGX-ST, regardless of the outcome of the review. SGX-ST may grant a waiver of the 
trade review fee where it deems appropriate.” Administrative costs, no matter how miniscule, can add up when 
we consider the loss of capital and liquidity that is incurred in parallel. 








Proponents of DLT may not be supportive of a regulator becoming a standard feature of trading markets, on the 
basis that it runs contrary to a "distributed" system. To that end, it may be worthwhile to consider the following: 
Does a network of distributed nodes, each adhering to a common set of rules, amount to a distributed system, 
or a centralised one? 





Forget the physicality of entities and the answer is clear: systems built on DLT will always be centric in nature, 
even without the installation of an arbitrator. On this note, a 2016 paper published by the ECB on distributed 
ledger technologies in securities post-trading concluded that “irrespective of the technology used and the 
market players involved, certain processes that feature in the post-trade market for securities will still need to 
be performed by institutions". This further substantiates the need for governance of blockchain applications in 
financial markets. 








Later in this report, we will also explore the implications of an arbitrator presence in a DvP-on-DLT securities 
settlement model - not to undermine the technology, but to enhance its operation. 


41 Retrieved from Rule 8.6.3, section 8.6, Chapter 8 of SGX-ST Rules, Section C — Market Structure, SGX Rulebook. [http://rulebook. 
sgx.com/en/display/display_viewall.html?rbid=3271&element_id=1117] 


42 Retrieved from Rule 8.6.4, section 8.6, Chapter 8 of SGX-ST Rules, Section C — Market Structure, SGX Rulebook. [http://rulebook. 
sgx.com/en/display/display_viewall.html?rbid=3271&element_id=1117] 


43. Retrieved from “Distributed ledger technologies in securities post-trading”. European Central Bank. April 2016. [https://www.ecb. 
europa.eu/pub/pdf/scpops/ecbop172.en.pdf] 
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Solution architecture 


In this section, we examine the architecture of solutions proposed by the technology partners, including their 
key design elements, and characteristics of each DLT pair used in the respective solution. 


Solution design by Anquan Capital 
In Anquan's solution design, the securities ledger had been developed with Anquan's permissioned blockchain, 
while Quorum was selected for the cash ledger (see Figure 10). 


Figure 10: Anquan's high level architecture 
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Figure 11: Anquan's permissioned blockchain 
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Securities ledger on Anquan’s permissioned blockchain platform 

Anguan's permissioned blockchain is a permissioned variant of Zilliga, a public blockchain platform tailored to 
facilitate high-throughput, data-driven, and distributed applications with low transaction fees, as a solution to 
Ethereum's main shortcomings (see Figure 11). 


Key features of Anquan's permissioned blockchain include: 


e Scalability 
The blockchain platform makes use of a technique known as network sharding, where the entire network is 
divided into smaller sub-groups of nodes, and each subgroup is able to process transactions in parallel. 


e Shard creation 
To avoid the risk of an attacker taking control of a shard, each node is randomly assigned to a shard. Shards 
are reshuffled at periodic intervals to mitigate the risk of collusion between participants over time. 


e Network consensus protocol 
Practical byzantine fault tolerance protocol (PBFT) is employed for consensus within each shard. This 
protocol's performance scales with network size and ensures transaction finality without confirmation once 
the PBFT proposes a block. 


Security protection against malicious nodes 

PBFT requires a correct leader to begin each phase of block creation, and the view change protocol replaces 
a malicious node leader when the consensus protocol is stalled. This results in an independent node system 
that self manages according to the majority. 


e Smart contract intermediate-level language (Scilla) 
A proprietary smart contract language was developed to impose a structure on smart contracts, making 
applications less vulnerable to attacks by eliminating vulnerabilities directly at the language level. It also makes 
applications inherently more secure and amenable to formal verification. 


Privacy with trusted execution environment 
All nodes run on machines with Intel Software Guard Extensions as a Trusted Execution Environment, allowing 
each node to verify all encrypted transactions while only revealing unencrypted data to authorised users. 


Unique features of design 
There are several unique features of this design, including: 


* Distributed atomicity 
To safeguard participants, atomicity is guaranteed without a centralised arbitrator through specific design 
elements. Although DvP-on-DLT may possess design flaws that expose the buyer to potential risks, this can be 
mitigated by guaranteeing transfer instructions after both participants have committed to the ledger. 





Integrates with existing payment systems prototype 
Interoperability not only applies because the DvP application operates two distinct ledgers, but also because it 
is integrated with the payment system developed in Project Ubin Phase 2. 


Scalability 
Linear scalability achieved through PBFT consensus algorithm and sharding enables cross-chain atomic swap 
without the need to wait for confirmation from several blocks. 
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Key takeaways 


In Anguan's implementation, specific design elements were taken into consideration to ensure transaction 
atomicity for DvP success without the need of an arbitrator. However, the arbitrator is still crucial in this 


Delivery versus Payment on Distributed Ledger Technologies | Project Ubin 


approach as it can override the time lock mechanism in the case of a failed exchange, and address the potential 


liquidity risks. 


As blockchains evolve rapidly, there is a need for consistent development support across multiple versions of the 


same blockchain, as many problems arise when different version updates are not compatible with one another. 


Additionally, the privacy model for Quorum relies on binaries located on each node to generate and verify the 
Zero Knowledge Proofs (ZKP). However, to implement DvP capability on Quorum, a new smart contract was 
added to enable atomic swaps, which is not compatible with ZKP privacy features. As the payment capabilities 


defined in Project Ubin Phase 2 were out of scope for this project, an attempt was not made to change the 


binaries to account for the DvP smart contract. It is important to note, however, that projects built using ZKP 


should account for this added complexity. 


Solution design by Deloitte 


In Deloitte's solution, the securities ledger had been developed with Hyperledger Fabric technology, and the 


cash ledger with Ethereum technology (see Figure 12). 


Figure 12: Deloitte's high level architecture 
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Figure 13: Hyperledger Fabric 
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Securities ledger on Hyperledger Fabric technology 

Hyperledger Fabric technology was chosen for the securities ledger because as a permissioned DLT, it is 
underpinned by a modular architecture delivering high degrees of confidentiality, resiliency, flexibility and 
scalability (see Figure 13). In addition, it is also able to accommodate pluggable implementations of different 
components and the idiosyncrasies of different ecosystems. 


The securities ledger possesses several key features: 


* Asset definition 
By defining assets digitally and enabling participants to agree on both their representation and 
characterisation, the securities ledger is able to facilitate the exchange of both tangible and intangible asset 


types. 


Security 

Permissioned membership provides an exclusive blockchain network where participants understand that all 
transactions are traceable by authorised regulators and auditors to ensure compliance with standards and 
prevent unauthorised participation. 








e Privacy 
Hyperledger Fabric uses channels to safeguard confidentiality of certain data elements, such as user identity, 
by providing data on a need-to-know basis. This is particularly relevant to the financial markets, where buy-side 
participants may require anonymity in their transactions to maintain competitiveness and meet regulatory 
requirements. 
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e Immutability 
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With an immutable shared ledger that encodes the entire transaction history for each channel, auditing and 
dispute resolution processes can be made more efficient. 


Scalability 


The chaincode execution is partitioned from the different parts of the transaction ordering to allow limitations 
to be placed on the required levels of trust and verification across node types. As a result, network scalability 
and performance is enhanced. 


Unique feature 
There are severa 


s of design 
unique features of this design, including: 


e Centralised user credential management 


Typically, token 





ised assets are secured with the use of the owner's private key, and it 


is the owner's 


responsibility to keep the private key secure. In this solution design, however, an authorised third party is able 
to provide key custody service by holding an escrow key, and endorsing transactions with its signature. 


e Semi-centrali 


Tokenised assets are common 


sed DvP process with the arbitrator 


y transacted in a disintermediated process that is more efficient and lower in 


cost. However, without a centralised process and an avenue for arbitration, the buyer/seller will have to bear 


any losses that are incurred. In 


this design, disintermediation is still maintained at a process level, but an 


arbitrator is introduced as a trusted third party with provenance over both ledgers for dispute resolution. 


e Smart contracts and public key infrastructure 


The DvP logic is implemented i 





external parties. Atomicity of the transaction is maintained through smart contracts. 


e Turing-complete blockchain solution compatibility 
In this Ethereum/Hyperledger Fabric blockchain pair, the solution design is built on open source technology, 
and therefore its design enables compatibility with other Turing-complete blockchain platforms. 


Key takeaways 


In Deloitte's 


implementation of the DvP prototype, a huge emphasis was placed on 


and enabling the control of assets. Transaction and settlement can only proceed a 


participant signs 
or SGX). Meanwh 


ile, the users' private information remains confidential during the sett 


process only requires a proxy address to identify a recipient and enable the transfer. 


Deloitte’s solutio 





nthe smart contracts for the transaction to be reviewed and audited by 


protecting user privacy 
fter an authorised 


and endorses the transaction with the secure secret issued by service providers (such as MAS 





ement process, as the 


n guarantees atomicity of transaction, and highlights the importance of governance, in the form 


of an appointed arbitrator, in protecting individual interests. A self-enforcing, but not self-executing, feature 
seller and buyer can complete the settlement transaction once the smart contract's conditions 
over-reliance on the blockchain application. The solution also employs a user-centric design to 


ensures that the 
are met, without 
give market parti 











cipants more control over the status of their transactions. 
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Solution design by Nasdaq 

In Nasdaq's solution, the securities ledger had been developed with Chain Core ledger technology, and the cash 
ledger with Hyperledger Fabric technology (see Figure 14). The solution is built to be agnostic to the underlying 
DLTs, separating the smart contracts from the DLT dependency. 


Figure 14: Interledger DvP for Hyperledger Fabric and Chain Core technologies 
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Figure 15: Nasdaq's architecture and solution design 
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Both ledgers and the smart contract initiation can be managed through one harmonised, role-based DvP API. 
Additionally, for the purpose of the proof of concept, two https connections were offered for direct access to 
each DLT implementation and their respective log files to validate the movement of the assets as they occurred 
on each ledger. The Nasdaq Smart Contracts Engine instantiates smart contracts according to the business rules 
and workflows that have been agreed upon. 
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Securities ledger on Chain Core technology 

Chain Core was built specifically for large enterprises. It enables companies to build private blockchain networks 
that provide both the decentralisation and cryptographic security of public networks, and the performance, 
scalability and confidentiality needed by commercial applications. Chain Core also enables cross-network and 
cross-protocol transactions, and has native support for smart contracts. 


The Chain Core platform 

The securities ledger was built using Chain Core, and smart contracts were created to handle hash-locked, 
multi-signature conditions, and recovery (see Figure 16). Chain's blockchain standard, known as the Chain Open 
Standard, was developed through partnerships with major financial services leaders such as Nasdag, Visa, 
Fidelity, Citigroup, Fiserv, First Data, and R3CEV. The Chain Core platform possesses several key features: 


Private and secure 
Chain supports private blockchain networks (in contrast to unpermissioned blockchain networks) and enables 
the network certificate authority to determine who can participate and transact on the network. Network and 
asset security is ensured through multi-signature key configurations, hardware security appliances, and full 
network validation. 








Confidentiality and anonymity 

Through the use of one-time-use addresses, transaction-level encryption, and data management services, 
the Chain Open Standard ensures confidentiality of data and transactions at a level beyond other blockchain 
protocols. Anonymity could also be achieved by encrypting data before transmission, or by setting up a 
specific channel to restrict data flow to only between the parties involved. 


Speed and scalability 
Chain's networks are designed to process high volumes of transactions: in production tests, it has achieved a 
rate of over 5,000 transactions/second, and this is limited only by the speed ofthe network and hardware. 


Use of smart contracts 
The Chain Open Standard has native support for a variety of smart contract structures to facilitate 
sophisticated transactions such as automated swaps in different marketplaces. 


Interoperability 
Chain networks, while private, can be configured to be interoperable with one another, and with other 
emerging blockchain protocols at a standards level. 


Flexibility 
The Chain Open Standard supports a variety of data, key, and deployment environments to onboard network 
participants with greater ease. 
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Figure 16: The Chain platform stack 
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Unique features of design 
There are several unique features of this design, including: 


e DvP component with role-based APIs 
The overarching DvP component with role-based API enables users, who are indifferent towards the 
underlying DLTs, to execute the necessary functions using one API. Using a role-based API, the user can also 
retrieve its account status for cash and securities, and perform all the necessary functions such as signing 
contracts with its private key, or inputting the secret on both ledgers. 


e Smart contract engine 
A generic smart contract engine was built to facilitate the creation of smart contracts independent of the DLT. 
The smart contract engine allows the user to define the criteria ofthe smart contract in a human-readable 
format and execute transactions on each DLT. 


e Fully security hardened cloud solution 
The design is fully containerised and can be deployed as a fully security hardened cloud solution for public 
or private operations, and to both back-end operations and user interfaces. The infrastructure also ensures 
configurability and elasticity by including a clear secure separation between the two blockchains and smart 
contracts, in addition to supporting locally installed user interfaces connected to the back-end in the cloud. 


Such an operational architecture has the advantage of being easy to scale and access, and enables the 
efficient use of resources. A single secure, role-based API is required to access both ledgers and the smart 
contracts, and also acts as an encapsulation layer for the specific DLT implementation so that a change of the 
underlying DLT technology will not affect the API and the resulting user experience. 


e Containerised architecture 
The application will be operated in a cloud environment, with all application components dockerised for 
efficient deployment and portability. In this way, containerised deployment of applications becomes possible, 
regardless of the infrastructure. Three points of access were designed for the environment - one for each API 
component to enable proper testing and verification of the DvP solution. Additional points of access were also 
made available to enable verification with individual DLT APIs through which successful transactions have been 
completed. 
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Key takeaways 
In Nasdaq's model, the solution is designed to be dynamic, and can be easily adapted to suit the eventual 


market rules and practices that will apply for DvP settlemen 
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t. Additionally, although arbitration is established 


in this model to increase investor confidence by providing an avenue for recourse, it may be unnecessary to 
oversee and govern all transactions. Lower value transactions could, therefore, be automated to increase 


efficiency. For example, immediate DvP settlement can occur au 
than a predetermined threshold. 


One design consideration was the need to ensure that the solut 
The smart contract engine that manages contract execution is n 
a separate layer above the core DLT layer to facilitate the switchi 
smart contract logic or the user interface encapsulating the DLT 


With respect to privacy, the overarching architecture design for 


tomatically for transactions with values lower 





on design can be deployed for any DLT platform. 
ot bound to specific DLT platforms, but built as 
ng of the underlying DLT without changing the 
implementation. 





the DvP component supports privacy handling 


on different levels. Anonymity can be established on the API layer or within the platform layer by generating a 


one-time public key for each transaction, such that an outside vi 








ewer would be unable to determine the identity 


of the participants. Further anonymity could also be achieved by encrypting data before transmission, or by 








setting up a specific channel to restrict data flow to only betwee 


n the parties involved. 
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Conclusion 


Observations about prototypes 
During the project and prototype development, we have identified five key observations and future 
considerations that will need to be explored in further phases of Project Ubin (see Figure 17). 


Figure 17: Observations about Project Ubin (DvP) 
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Rulebook integration 

The current landscape of primary participants largely involves members?“ of an exchange, who provide a set of 
rules to maintain the operations of a fair, orderly, and transparent marketplace as determined by the exchange. 
In addition, smart contracts are use case-agnostic to accommodate many different logic conditions. 


This project seeks to explore whether smart contracts can act as a replacement for compliance requirements 
due to the inherently integrated rulebook by, for example, having arbitration built into the smart contracts’ 
conditions to validate transfer instructions. Furthermore, error margins that define an erroneous trade can be 
pre-programmed into the trade to prevent market participants from partaking in such trades. 





Here, the project has provided a proof-of-concept that the functionalities of smart contracts can be used to 
programme conventional rulebook conditions. This could result in situations where a central bank or financial 
services institution may need to carry out enforcement actions on members who are located across multiple 
jurisdictions and therefore subjected to different degrees of regulation scrutiny and compliance standards. 

















One such application could be coupon payments" associated with the underlying fixed income security, where it 
can be instituted with smart contracts to enable transactions on separate DLT implementations. 


Compression of settlement cycle 

n Singapore, the current market practice on settlement cycles is T+3. Having a solution design that is built on 
DLT for interledger operability helps to illustrate the potential of compressing the post-trade settlement process 
to T+1 or even round-the-clock, real-time settlement. 





oving the industry forward to T+1 or real-time settlement may have many implications. For instance, with a 
shorter timeframe to settle, it will lower exposures to counterparty, principal and liquidity risks. Banks will have 
to rethink their liquidity and risk management practices to remain competitive. As the compression of the trade 
settlement cycle takes effect, regulators have to constantly re-evaluate and update existing rulebooks and 
regulations that governs the time and duration for settlement, particularly with arbitration to ensure a fair and 
orderly market. 





44 Firms must (i) meet capital requirements, (ii) have clearing members to contribute to a clearing fund, which in turn creates a 
liquidity requirement held by the market participants, (iii) have all participants agree to abide by the trading rules of the exchange 
in the event of a dispute, and submit to the judgement of the exchange. 


45 Interest payment paid by the issuer to the bondholder. 
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Arbitration design 

The interledger transaction for cash and securities settlement have highlighted the principal risk exposure to the 
counterparties during specific segments of the process flow when participants do not abide by the transaction 
sequence, such as when the buyer does not discharge the securities contract to withdraw the securities before 
the time boundary expires, resulting in a situation where the seller can then expire the contract and recover the 
securities while having received the cash payment. 


Therefore, it is crucial to appoint an arbitrator for dispute resolution, and the solution design has revealed 
several possible intervention opportunities. The arbitrator can assess the circumstances of the disputed trade 
before passing judgement on possible recourse, whether it is (i) recovery of cash payment for the buyer, or (ii) 
moving ahead with the transaction by transferring the ownership of the underlying asset to the buyer. This can 
be accomplished using smart contracts that are established at the beginning of the settlement cycle or upon the 
discharge of the cash contract. 











Further analysis is required to provide a more robust arbitration framework. For example, during the arbitration 
period, the buyer may be exposed to liquidity risk if the seller possesses insufficient funds after the transaction 
has reached finality. Would the recovery contract provide sufficient safeguards for the buyer with a programmed 
condition on the cash reserve“ requirement of the cash ledger balance? Or should there be a smart contract 
that is built on top of the cash payment to restrict fund movement? 





Enhanced security and privacy 

The prototypes that were developed are compatible with different types of trading platforms, including CLOB”” 
or OTC request for quotes/auctions. This has resulted in the use of different models by our technology partners 
to safeguard privacy. 


To maintain market competitiveness yet still abide by regulatory requirements, the identities of the participants 
of the trade should not be known to one another, except for OTC trades, especially in the financial services 
industry where anonymity is paramount. In our proposed DLT solution, an inclusion of a secure-PDF containing 
the secret is an important off-chain and out-of-band feature to ensure that investors’ interests are protected. 


Verification of recipient 

An investor will be able to use the PDF that contains either a randomly encrypted address (a proxy for the public 
key), or the public key to verify its identity with the execution platform (user interface) before agreeing to the 
transfer. 


Secret-sharing 
The secret used for the transaction is sent through an encrypted PDF and is independent of the blockchain 

network. As it is not stored or propagated through the blockchain network, this ensures that the secret is not 
made known to other participants in the network. 


The prototypes have adopted various ways to ensure that security and privacy is not compromised with an 
off-chain and out-of-band design. These includes remodelling the CLOB where the certificate authority keeps a 
record of its registered users, and using it to generate a pseudo address that is used for transactional purposes, 
without revealing the identity to the participants in the market. Alternatively, an OTC model can be adopted, 
where the buyer and seller are able to review the identity of the counterparty, in a setup that is similar to the 
existing market design. 























46 Aspecified minimum threshold amount for deposits held with a central party. 


47 Centralised limit order book that holds the record of all unexecuted limit orders maintained by a stock exchange. 
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Liquidity and market structure 
SGS functions as an important financial instrument for money market liquidity. Conventionally, 
liquidity is affected by a multitude of factors, such as the availability of intraday credit, and the 
type of settlement mode. When settlement is achieved on DLT, liquidity efficiency will be lower 
than conventional market setups due to the underlying mechanism that locks assets to their 

corresponding ledgers. 





Given that disputes may arise, the assets associated with these transactions may be locked for an 
extended duration until the contract expires, or reaches a state of resolution, before it is returned 

o the respective asset holders. This will have an impact on the participants and market liquidity 
because the underlying assets cannot be utilised for other transactions during this duration. These 
mechanisms are part of the solution design, and are required to serve and safeguard investors’ 
interests. However, more research needs to be done to evaluate the effects on market structure and 
iquidity. 





Future considerations 

Project Ubin has demonstrated the functional capabilities ofthree different blockchain pairs to 
establish an interledger DvP settlement system, and highlighted the need for an arbitrator for 
dispute resolution to maintain a fair and orderly market structure. 





Liquidity Savings Mechanism (LSM) 

Following the discussions from Phase 2 of Project Ubin, the LSM could be triggered by the RTGS 
system centrally using a predefined interval. The project has highlighted the importance of ensuring 
fairness to all participating banks with regard to their liquidity position before initiating gridlock 
resolution. One proposed method is to have a reserve requirement set aside for LSM processing by 
decoupling LSM from the fund transfer. 





Project Ubin (DvP) has expanded on the possibility that an appointed arbitrator can monitor and 
initiate the gridlock. As the arbitrator now holds the escrow key, it can resolve any disagreements 
on LSM. One consideration is the need to maintain full transparency for all participants with the 
processes used for monitoring the liquidity positions and cut-off time. This would ensure a level 
playing field and a neutral stance taken by the arbitrator as a service provider. Nonetheless, more 
research has to be undertaken to evaluate the current regulatory infrastructure that governs the 
financial services industry if LSM on DvP is put into practice to understand its implications and 
associated risks in the marketplace. 


























The effects of a coupled DvP LSM system could also have potential benefits for liquidity management 
and help to reduce the amount of settlement delay experienced by market participants (see Figure 
18). A settlement period of T+3 is given to provide a buffer for participants to secure the underlying 
assets for settlement. Settlement delay increases as the participants have lower liquidity, resulting 

in potentially unsettled trade obligations that can only be resolved with offsetting positions or 
additional injections of liquidity. In this scenario, LSM coupled with DvP-on-DLT can potentially 
alleviate this problem by ensuring that liquidity efficiency is maximised and excess liquidity can be 
reallocated. The compression of settlement cycles could also result in new liquidity management 
strategies, as banks can leverage LSM to achieve better liquidity and flexibility in trade settlement 
and execution. 
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Figure 18: DvP coupled with LSM 
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Round-the-clock operations 
Building a solution design on DLT for interledger operability illustrates the potential of co 
trade settlement process to T+1 or potentially even round-the-clock, real-time settlemen 


mpressing the post- 
t. This can be further 


explored for cross-border transactions where time-zone differences could result in a delay in settlement times, 


thereby exposing participants to unnecessary foreign exchange rate fluctuations and pr 


Before such an endeavour can be pursued, however, there may be potential business an 
need to be addressed in the current process: 


incipal risks. 


d regulatory issues that 








e Foreign exchange rates for non-SGD transactions after trading hours for non-DLT part 





icipants 


e Pricing for transaction and handling fees by financial intermediaries involved in transaction processing 


e Varying degrees of stringency in regulatory requirements for cross-border transfers 


e Operating hours and cut-off times for different banks 


Operational service level agreements between domestic banks and correspondent banks 
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Merging of trading and settlement processes 

The conventional models of trade order execution and post-trade settlement have been distinctly 
separate processes, and an array of specific functionalities built for the purpose of counterparty 
matching or settlement have created a void of inefficiencies. By showing that smart contracts can be 
used as a tool for rulebook integration, Project Ubin (DvP) has highlighted the possibility to converge 
these processes through the application of a specific DLT solution design that utilises contract locks 
within multiple ledgers for cash and securities to safeguard investors’ interests during and post- 
trade. 





Specifically, smart contracts for the transaction are created during the trade execution phase to 
ensure that both participants possess the necessary assets required to proceed with settlement. 
This would ensure that participants are able to settle the obligations of the trades that are executed. 





Broadening of suitable asset classes and markets 
Project Ubin (DvP) identified the use case of government securities, but the underlying blockchain 
technology could have many other implied use cases for other asset classes, such as securities, 
corporate bonds, commodities, and derivative products. The current market setup has distinctly 
different clearing houses for specific asset classes. For example, the Singapore Exchange Derivatives 
Clearing (SGX-DC) is responsible for clearing derivatives, while the Central Depository acts as a 
clearing house for equities and fixed income. This distinction arose from the different underlying 
risks associated with the different asset classes. 














Another area where DLT could become potentially revolutionary is derivatives, which has a broad 
supply chain network. DLT would enable all transaction information to be stored and traceable 
through the transaction history in ledgers. Essential information, such as product definition, transit 
location, and price, can be captured and stored, a feature that is essential not only in derivatives, but 
also in any maritime trade-intensive goods. 











Alternatively, being able to tokenise assets and give them a digital identity would enable illiquid 
assets (such as real estate and art pieces) to be traded outside of conventional means. Interledger 
operability could potentially also open up opportunities for cross-border trade settlement on 
DLT. With DLT, additional asset classes can be traded unconventionally, and more markets can be 

connected using DLT, with the result being greater liquidity and more investment opportunities for 
the global investor community. Ultimately, DLT would be able to empower new business models for 
the financial services industry, while revamping existing primary and secondary market structures. 
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Appendix 


Figure 19: Rights and obligations model in DvP-on-DLT for securities in Project Ubin (DvP) 





Who can? 


SGS Market Committee (MAS 
for SGS and SGX for other 
securities) 


Exercise what rights? 


Arbitrate DvP securities transfer 
(to buyer) 


On which obligations? 


Sell-side DvP Tx1 to transfer 
securities (from seller) 





Arbitrate DvP securities recovery 
(to buyer) 


Sell-side DvP Tx2 to transfer 
securities (from seller) 








Central bank (MAS for central 
bank-issued cash-depository 
receipts) 


Arbitrate DvP cash transfer (to 
seller) 














Arbitrate DvP cash recovery (to 
seller) 


Buy-side DvP Tx3 to transfer cash 
(from buyer) 








Buy-side DvP Tx4 to transfer cash 
(from buyer) 





Participant A (seller) 


DvP transfer securities (to buyer) 


Sell-side DvP Tx1 to transfer 
securities (from seller) 





DvP recover securities (to buyer) 


Sell-side DvP Tx2 to transfer 
securities (from seller) 








DvP transfer cash (to seller) 


Buy-side DvP Tx3 to transfer cash 
(from buyer) 





Participant B (buyer) 


DvP transfer securities (to buyer) 


Sell-side DvP Tx1 to transfer 
securities (from seller) 





DvP transfer cash (to seller) 


Buy-side DvP Tx3 to transfer cash 
(from buyer) 








DvP recover cash (to seller) 





Buy-side DvP Tx4 to transfer cash 
(from buyer) 

















Participant A (seller) Sale/when issue (to buyer) Issue of sale/when issue (from 
seller) 
Cancel sale/when issue (to buyer) 
Transfer free of payment (to Borrow/lend/transfer of securities 
transferee) (from transferor) 
Participant B (buyer) Reject or confirm sale/when issue Issue of sale/when issue (from 


(to buyer) 


seller) 





Cancel sale/when issue (to buyer) 





Note: Contracts shaded in grey are out of scope and beyond the purpose of DvP settlement. For example, the confirmation of deals can be 


carried out on the trading platform. 


46 


Delivery versus Payment on Distributed Ledger Technologies | Project Ubin 


Figure 20: Rights and obligations model in Phase 1 and 2 of Project Ubin 

This table summarises Project Ubin models“ for central bank-issued cash-depository receipts with MAS. At this 
juncture, the scope excludes DvP for domestic securities settlement and PvP for cross-border transfers, for 
example, with another central bank in a different currency. 


Who can? 


Exercise what rights? 


On which obligations? 





Financial institutions (FIS), 
including CDP, SGX Derivatives 
Clearing Limited, and banks 


Pledge cash 


Fl's own cash 





Transfer cash 


Sender) Fl's own cash 
Receiver) Other Fl's cash 





Reprioritise queued cash transfer 





Settle queued cash transfer 


Defer queued cash transfer 





Cancel queued cash transfer 


Sender) Fl’s queued cash transfer 


Receiver) Other Fl's queued cash 
transfer 





Propose netting plan on queued 
cash transfers 





Participate in proposed netting 
plan on queued cash transfers 





Settle proposed netting plan on 
queued cash transfers 


Fl’s nettable queued cash 
transfers 

Other Fl's nettable queued cash 
transfers 

Sender) Fl’s own cash 

Receiver) Other Fl's cash 





Redeem cash 


Fl's own cash 


Central bank, such as MAS 


Reject/approve cash pledge 


Fl’s cash pledge 
Fl’s own cash 





Reject/approve cash redemption 


Fl’s cash redemption 
Fl’s own cash 








48 Refer to MAS Project Ubin Phase 1 and Phase 2 reports, including Open Source, for more information. [http://www.mas.gov.sg/ 
Singapore-Financial-Centre/Smart-Financial-Centre/Project-Ubin.aspx] 
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Figure 21: Template of electronic password mailer 

This figure illustrates a template of the electronic password mailer containing the transaction password required 
to hash-lock the DvP proposal on both sides: seller-side DvP to unlock buyer's cash, and buyer-side DvP to unlock 
seller's securities. 


DATE/TIME: 17-AUG-2018, 15:08:28 


Dear Sir/Madam, 


These are your details required to approve the transaction at Digital@SGX. 


NOTES: 

Please follow the security guidelines below to safeguard against fraudulent transactions: 
1. You will need your password (found in this password mailer) to approve the transaction. 
2. For security reasons, do not disclose your password to anyone. 

3. If you need further assistance, contact us at +65 6535 7511 or asksgx@sgx.com. 


: SGX == Deloitte. 


Field Name [Length| Field Description 
DateTime 15 to 36 [2a ||Format in DD-MON-YYYY, HH24:MI:SS 


LegalName 5 to 55 |[50 ||Investor's Legal Name 


[Addressini 5 to 55 [po Investor's Address Line 1 


ssLn2 5 to 55 Bo | Investor's Address Line 2 
[adaressin3 | 5 to 55 Bo | Investor's Address Line 3 
TransactionRef|[5 to 91 [86 [transaction Hash (e.g., SHAS12bit) in Base64 Encoding = 
[ArbitratorSig |[45 to 55/10 | bitrator's Signature (e.g., Elliptic-Curve over a 384bit prime field with SHA2Sébit) 
25 [PasswordImage | 70 to aojo |] Password Image (e.g., case-sensitive, alpha-numeric) 
25 PasswordQRCodel[85 to 90|[5 [Password Quick Response Code (QRCode) 


2 
3 
4 
5 
6 
7 
8 
9 
0 
1 
2 
3 
2 
5 
6 
7 
8 
9 
0 
1 
2 
3 
4 






























































“TAI 
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Figure 22: Secure PDF signature validation 
To prevent forgery and strengthen investor protection, investors are able to validate the digital signature of the arbitrator's public key. 


Digital signatures are also a cornerstone of Singapore's Smart Nation vision, where it is referred to as the National Digital Identity. 














Signature Properties x 
Signature validity is UNKNOWN. 
Signing Time: 2018/08/17 15:09:19 +08'00" 
Certificate Viewer x 
Validity Summary 
This dialog allows you to view the details of a certificate and its entire issuance chain. The details correspond to 
The document has not been modified since this signature was applied. the selected entry. Multiple issuance chains are being displayed because none of the chains were issued by a 
trust anchor. 
The certifier has specified that no changes are allowed to be made to this 
Show all certification paths found 
document. 
s Sne P A 3 3 Si G it Sex Detail: j ici j 
The signer's identity is unknown because it has not been included in your list of | EROS Gove Se SEO di [Summary] Detalls |Revocation| Must odes Legal Novice 
trusted certificates and none of its parent certificates are trusted certificates. DI 
Certificate data: 
Signing time is from the clock on the signer's computer. 
SO "9 P Name Value A 
Signature was validated as of the signing time: [3] Serial number 00 F4 AB 21 14 CC C6 1E 3F 
2018/08/17 15:09:19 +08'00" G Validity starts 2018/08/16 11:28:20 +08'00' 
GÆ Validity ends 2028/08/13 11:28:20 +08'00' 
7 Public k UBI ) 
Signer Info [fl SHAI digest of pu... <see details> 
yee [ia] X.509 data 30 82 03 1E 30 82 02 A3 02 09 00 F4 AB... 
Path validation checks ful. 
Aaah neds eke seca [Fl] SHAI digest CC A8 2F C7 8D E2 14 10 91 87 08 40 01... 
[i] MDS digest 78 86 AF 3C 3B B6 AB 98 86 C6 81 58 C... 











Revocation checking was not performed. 


30 76 30 10 06 07 2A 86 48 CE 3D 02 01 06 05 2B 81 04 00 22 03 62 00 04 
69 DF 34 82 82 9F 1A 31 3B 6F F1 1C DB 51 OD 8A C4 A2 6F CF 03 E9 C9 

EB 91 CA 3E 2E C8 92 D4 46 01 00 DC D7 8A F8 EB 19 E0 4E 8C 35 25 F9 

54 DC CO 77 53 D2 D8 F2 89 5A F8 43 F1 4B 5D 99 3F 42 94 3C DO DO ED 


|A4 61 FC 6D DF CF E0 61 C2 A5 E0 A2 2B A4 AO FD 28 A4 E2 44 60 45 CE 





Advanced Properties... Validate Signature Close 








3B 2C F7 B2 
Certificate Viewer x 
This dialog allows you to view the details of a certificate and its entire issuance chain. The details correspond to 
the selected entry. Multiple issuance chains are being displayed because none of the chains were issued by a 
trust anchor. < > 
Show all certification paths found © This is a self-signed certificate. The selected certificate path is valid. 
Summary Details Revocation Trust Policies Legal Notice The path validation checks were done as of the signing time: 





2018/08/17 15:09:19 +08'00' 
a Singapore Government Securities Market Committee 
Monetary Authority of Singapore OK 
Issued by: Singapore Government Securities Market Committee 
Monetary Authority of Singapore 
Valid from: 2018/08/16 11:28:20 +08'00" 


Valid to: 2028/08/13 11:28:20 +0800" 





Intended usage: [Not Specified 


Export... 





< >| 


© This is a self-signed certificate. The selected certificate path is valid. 


The path validation checks were done as of the signing time: 
2018/08/17 15:09:19 +08'00' 


OK 
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DvP model by Anquan Capital 


Figure 23: Settlement process flow 


















































Participant A Participant B SGX 
SGX picks x, y and computes z = f(x,y) then 
Phase 1: sends x and b = H(z) to Participant A, and 
Offline — y and a = H(x) to Participant B 
preparation 
< < 
Phase 2: Tx,: Send security to Participant B 
Commit Spend condition: Provide z s.t. H(z) = b 
; > 
transactions Tx,: Send funds to Participant A 
Spend condition: Provide x s.t. H(x) = a ; 
Phase 3: l Participant B learns x, and can now 
Claim assets Tx,: Provides x to claim Tx, compute z 
> 
Tx,: Provides z to claim Tx, 
> 
Figure 24: Detailed settlement process flow 
SGX provides secrets 
and parameters to 
participants 
Alice commits to the 
trade with Tx, 
ae nas DO: Bob verifies that hashlock 
submitted Tx, i 
parameter in Tx, is H(z) 
before Tx, 1 
>) ; > 5 
Bob uses timelock | Expires : Arbitrator of payment 
Bob commits to the ; 
mechanism to 1 i ___> DLT overrides 
trade with Tx, 


recover his cash 


| 


Alice uses timelock 
mechanism to recover 


her securities 
NG of 


Trade is cancelled 

















50 








€ Pi 
Alice verifies that hashlock 
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a > 





Alice uses secret x to 
claim payment with Tx, 








hashlock mechanism 
Ne a 
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a N 
Arbitrator of securities 
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DvP model by Nasdaq 

Settlement process flow 

The settlement process flow was designed with the following parameters: 

e Traders are anonymous. 

e Short-selling of securities is allowed. 

e The seller of the securities defines the time boundaries that would apply for the settlement of trade (when 

cash and securities shall be delivered). The buyer confirms the conditions when it is accepting the order. 

e The cash contract is discharged first. That is, the cash transaction is performed first inthe settlement 
execution process. 

e Settlement failures are handled through arbitration. The arbitrator has the authority to retrieve the cash from 
related accounts to achieve settlement. 














The following series of activities are performed: 

Alice places sell order, and defines the time boundaries that would apply for settlement. 
. Bob accepts the order. 
The arbitrator initiates the settlement process. 

The contract engine creates three contracts: 

e Cash contract: First contract to secure the delivery of cash to the seller 

e Securities contract: Second contract to secure the delivery of securities to the buyer 

e Cash retrieval contract: Third contract to retrieve cash ifthe seller is short on securities 








Pi i O 





Figure 25: Settlement process flow 


Alice Bob 


O 


U fat 


Order accepted 
Settlement instructions 


| 


EN Arbitrator 


3 Settlement initiated 


Cash Securities Cash 
retrieval 
7 7 


4 Contracts created 
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DvP model by Deloitte 


Figure 26: DvP process in which buyer and seller successfully swap tokenised assets 
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order order the secret secret to 
from SGX lock 

server securities 





Tokenised cash ledger 
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Securities 
ledger 
verifies and 
confirms 
transaction 


Buyer gets 
the secret 
lock from 
securities 
ledger 





Trade 











Buyer 
inputs the 
secret lock 
to lock the 
cash 




















Seller 


cash with 
the secret 


Cash 
ledger 
verifies and 
confirms 
transaction 








Post-trade 


unlocks the 
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Payment 
completed 
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Securities 
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Completed 
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Figure 27: DvP process in which buyer and seller recover tokenised assets with arbitration 
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Legal notice 

The contents of this report are provided “AS IS” and intended for 
informational purposes only and should not be relied upon as operational, 
marketing, legal, technical, tax, financial or any other advice. You should 
consult with your legal counsel to determine what laws and regulations may 
apply to your circumstances. To the fullest extent possible under applicable 
law, each of Deloitte Consulting Pte Ltd (“Deloitte”), the Monetary Authority 
of Singapore (“MAS”), Singapore Exchange Limited (“SGX”), Anquan Capital 
Pte Ltd (“Anquan”) and Nasdaq (Asia Pacific) Pte Ltd (“Nasdaq”) is not 
responsible for, and will not be liable for any loss or damage sustained by 
you or any other party arising from, your use of the information contained 
herein (including errors, omissions, inaccuracy or non-timeliness of any 
kind) or any actions you may take or not take or assumptions or conclusions 
you might draw from such information. 


All intellectual property rights in, relating to or associated with this report 
remain vested in Deloitte, MAS, SGX, Anquan and Nasdaq and/or their 
respective licensors. You must not reproduce, translate, modify, adapt or 
publish this report or any part hereof without the prior written consent of 
Deloitte, MAS, SGX, Anquan, Nasdaq and/or their respective licensors, as 
applicable. 


All representations and warranties whether express or implied by statute, 
law or otherwise, including any warranty as to accuracy, timeliness, 
completeness, merchantability, satisfactory quality, fitness for any 
particular purpose, and any warranty relating to intellectual property 
ownership or non-infringement, are hereby disclaimed to the fullest extent 
possible under applicable law. 














Di “a we 
LA 


















ry s 
dy ante * 
gii Lee PEA 
. p gif! “nd 











} 


oo 


i me 


Sanna ae 
qu (10 ‘1300230 Peirt 


n “TTF 


ssi 


=. g 


eM i 


è WI A Pe oe E A 





Deloitte. 


Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited (“DTTL”), its global 
network of member firms, and their related entities. DTT (also referred to as “Deloitte 
Global”) and each of its member firms are legally separate and independent entities. DTTL 
does not provide services to clients. Please see www.deloitte.com/about to learn more. 


Deloitte is a leading global provider of audit and assurance, consulting, financial advisory, 
risk advisory, tax and related services. Our network of member firms in more than 150 
countries and territories serves four out of five Fortune Global 500° companies. Learn how 
Deloitte's approximately 286,000 people make an impact that matters at www.deloitte.com. 
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Deloitte practices operating in Brunei, Cambodia Guam, Indonesia, Lao PDR, Malaysia, 

yanmar, Philippines, Singapore, Thailand and Vietnam - was established to deliver 
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